In a computer, a sound is typically represented and stored in a digital format, herein called a "sound resource." A sound resource has various properties or characteristics such as data size, data rate and compression. For example, a sound resource typically has a data size of 8 bits or 16 bits. A sound resource may or may not be compressed.
To play a sound represented by a sound resource a computer includes sound hardware which converts the sound resource into an audibly-perceptible analog signal. Examples of sound hardware are, among others, a digital signal processor ("DSP"), a digital to analog converter ("DAC") and a frequency modulation chip ("FM chip"). Generally, sound hardware has an associated software driver which provides communication to the sound hardware, serving as an application programmer's interface ("API") to the sound hardware. Typically, the API's for software drivers of different kinds of sound hardware are distinct from each other. Herein, the term "sound hardware mechanism" is used to denote this hardware and, where appropriate, associated software drivers.
A sound hardware mechanism typically operates on sound resources having particular properties or characteristics. For example, a sound hardware mechanism may successfully operate only on sound resources having a data size of 16-bits and a sample data rate of 22 kHz. In that case, a sound resource having a different data size or sample data rate is converted into the proper format before the sound hardware mechanism is invoked so that the sound hardware mechanism can successfully operate on the sound resource.
In some computers, such as a '386 processor-based system running a Windows operating system which complies with a Multimedia PC ("MPC") specification available from Microsoft Corporation, Redmond, Wash., software applications communicate directly with a software driver for the sound hardware and, thus, each application is responsible for providing sound resources which are in a format useable by that sound hardware mechanism. In these systems, to play a sound an application which uses sound resources that are in a format which differs from that expected by the sound hardware mechanism converts the appropriate sound resources into the format expected by the sound hardware mechanism. Such conversion of sound resources may entail sample rate converting, decompressing, mixing or other formatting operations.
In such computers, to play sound using a particular sound hardware mechanism, a software application is programmed with specific "knowledge" on how to communicate with that sound hardware mechanism and with "knowledge" on how to convert its sound resources into the expected format for that sound hardware mechanism. Since sound hardware mechanisms typically have a unique API, e.g. an API which is distinct from the API's of other sound hardware mechanisms, a software application is typically limited to using sound hardware mechanisms for which it is specifically programmed. Thus, it is extremely difficult, if not impossible, for a software application to use additional or subsequently-developed sound hardware mechanisms without additional programming and recompilation of the software application.
In a Macintosh operating system, version 7.0, an intermediary software layer, called a Sound Manager, is provided so that software applications communicate with the sound hardware mechanism via the Sound Manager, rather than communicating directly. The Sound Manager, rather than the individual applications, is responsible for converting sound resources, if appropriate, into a format useable by the sound hardware mechanism. Thus, software applications using the Sound Manager to play sounds can play sound resources without having "knowledge" as to the format requirements of the sound hardware mechanism. Moreover, the Sound Manager permits multiple applications to concurrently access/use the sound hardware mechanism. For a more in-depth description of the Sound Manager in the Macintosh operating system, version 7.0, see "Inside Macintosh", Vol. VI, Chapter 22, Addison-Wesley Publishing Co., 1991.
Although a software application can use the Sound Manager without knowledge of or dependence on the actual sound-producing hardware available in the computer, the Sound Manager itself is tightly coupled to the sound hardware mechanism. Thus, the Sound Manager typically is rewritten to some degree and recompiled to port the Sound Manager to a new sound hardware mechanism or to take advantage of new features in existing sound hardware mechanisms. Since the Sound Manager performs audio data processing internally, using its own filters to decompress audio data, convert sample rates, mix separate sound channels, it is difficult to add other data modification filters or to replace the existing filters with new methods, e.g. a new sample rate conversion algorithm.